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Abstract 

Specifying  and  maintaining  the  semantics  of  data  used 
by  CAD/CAE  tools  is  often  accomplished  thmugh  writ¬ 
ten  documentation.  This  documentation  is  used  by  the 
tool  developers  and  is  not  usually  computer  process- 
able  which  makes  sharing  of  tools  and  libraries  very 
difficult  and  cumbersome.  In  the  OCT  data  manage¬ 
ment  system  developed  at  U.C.  Berkeley,  the  semantics 
are  referred  to  as  the  policy.  In  this  paper,  we  describe 
a  set  of  tools  that  has  been  developed  to  allow  the  user 
to  specify  and  store  the  semantics  (or  policy)  itself  in 
the  database,  and  ensure  that  new  instances  that  are 
added  to  the  database  will  be  semantically  consistent. 

1.  Introduction  and  Motivation 

OCT  is  a  data  manager  for  VLSI/CAD  appUcations 
[  I  },[2|  for  storing  information  about  various  aspects  of 
electronic  design.  OCT  was  designed  to  be  as  flexible 
as  possible  so  that  tool  developers  could  use  this  to 
develop  new  tools,  and  accommodate  different  design 
methodologies  and  design  flows.  Often  within  a  suite 
of  tools  like  Lager  (3).  the  developers  have  some  con¬ 
sistent  policies  across  tools;  however,  there  is  no 
“super  policy”  that  a  tool  developer  or  user  can  con- 
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suit.  This  is  because  the  policy  is  hard-coded  in  the 
associated  design  management  tool,  in  this  case. 
DMoct  |3].  [4j.  It  is  even  more  difficult  to  use  tools 
and  libraries  that  are  not  developed  as  part  of  the  same 
suite  of  tools.  To  use  tools  from  different  suites 
requires  translators  to  be  developed  and  used  to  map 
the  data  from  one  policy  to  another.  For  example,  using 
Lager  policy  and  the  octtools  policy  requires  the 
j>'tv2sym  and  sym2siv  uanslators  to  allow  designs  pro¬ 
duced  using  DMoct  to  use  the  TlmberWolf  tools(S]. 
This  proliferation  of  policies  does  not  foster  the  devel¬ 
opment  of  sharable  libraries,  primarily  because  DMoct 
would  have  to  be  modified  or  extended  for  new  library 
policies  such  as  for  PCBs  (printed  circuit  boards)  or 
MCMs  (multi-chip  modules). 

We  are  developing  a  system  for  board-level  synthesis 
(6]  and  chose  to  use  OCT  to  develop  a  sharable  library 
of  components!?].  We  also  had  as  our  goal  to  be  com¬ 
patible  with  the  system  design  tools  and  libraries  that 
are  part  of  the  SIERA  System  developed  at  U.C.  Ber¬ 
keley.  After  developing  a  policy  for  board-level  com¬ 
ponents  in  our  library,  we  attempted  to  use  the  SDL 
(Structure  Description  Language)  that  is  used  to 
describe  library  cells  and  define  the  parameterized 
netlist.  The  SDL  for  an  LM5SS  is  shown  in  Figure  3. 
DMoct  uses  the  SDL  to  create  the  SMV  (Structure 
Master  View),  that  is,  the  OCT  view  that  stores  the 
parameterized  netlist  Part  of  the  SMV  for  the  LM555 
is  shown  in  Figure  2. 

We  found  that  DMoct  had  to  be  modified  to  allow  the 
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LM555  Timer 

(^eot-cell  LMS5S  (PackiteCIur  PCB) 

(SIVMASTER  LM55S}) 

(p«rtmeten(PARTNAME  “LM555") 

(PARTTYPE  “ANALOG")) 

(net  Q  ((^Dt  (term  Q  (PINNUMBER  ’3) 

(TERMTYPE  SIGNAL)  (DIRECTION  OUTPUT))))) 
(net  R  ((pwent  (totm  R  (PINNUMBER  ‘4) 

(TERMTYPE  SIGNAL)  (DIRECnON  INPUT))))) 
(net  TR  ((pnnnt  (tetm  TR  (PINNUMBER  '2) 
(TERMTYPE  SIGNAL)  (DIRECTION  INPUT))))) 
(net  <y  ((perent  (term  Crv  (PINNUMBER  ‘5) 
(TERMTYPE  SIGNAL)  (DIRECTION  INPUT))))) 
(net  THR  ((pireni  (term  THR  (PINNUMBER  *6) 
(TERMTYPE  SIGNAL)  (DIRECTION  INPUT))))) 

(net  DIS  ((ptfcni  (term  DIS  (PINNUMBER  '7) 
(TERMTYPE  SIGNAL)  (DIRECTION  OUTPUT))))) 
(net  VOC  ((parent  (term  V(X  (PINNUMBER  ‘*) 
(TERMTYPE  SUPPLY))))) 

(net  GND(([«reni  (unnGND  (PINNUMBER ‘D 
(TERMTYPE  GROUND))))) 

(end-ndl)  \ 


Figure  1.  SDL  for  LM555 


Figure  2.  SMVfor  LMS55 
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description  of  the  components  for  our  board-level 
library.  In  fact,  the  Structure  Description  Language  also 
had  to  be  extended  to  handle  some  of  the  features 
required  for  representing  components.  Also,  we  were 
forced  to  use  certain  defaults  consistent  with  the  Lager 
policy  —  these  defaults  were  not  necessary  for  any  of 
our  tools  but  their  absence  would  not  allow  DMoct  to 
successfully  construct  the  SMV.  For  example,  Lager 
policy  requires  a  layout-generator  be  specified,  our 
policy  for  a  PCB  does  not  require  a  layout-generator. 
Finally,  the  current  Lager  policy  did  not  support  some 
other  OCT  features  tliat  we  required  to  make  our  com¬ 
ponents  compatible  with  components  in  SIERA  with¬ 
out  storing  redundant  information.  Redundant 
information  not  only  requires  more  physical  storage 
hut  it  also  contributes  to  maintenance  difficulties.  A 
change  in  the  library  policy  would  require  that  all 
occurrences  of  the  redundant  information  be  located 
and  modified. 

This  motivated  us  to  introduce  tlic  notion  of  a  template 
and  develop  PMoct,  a  policy  management  ttwl.We  cre¬ 
ated  the  template  view,  this  view  allows  the  user  to 
specify  the  policy  for  a  shareable  library  or  a  tool  or 
suite  of  tools  in  OCT.  The  template  view  is  used  by 
PMoct  to  cr-'ale  library  entries,  as  well  as  design 
instances,  that  is.  the  SMVs.  All  SMVs  aealed  from  a 
template  will  be  semantically  consistent  and  will  have 
the  correct  default  properties  and  values  as  well  as  a 
comsistent  set  of  user  specified  values.  If  policy 
changes  are  necessary,  only  the  infi)rmallon  in  the  tem¬ 
plate  view  needs  to  be  modified  and  PMoct  will  ensure 
that  the  ptdicy  changes  arc  transparent  to  PMoct  and 
other  UhiIs  and  across  other  libraries. 

We  give  a  brief  review  of  (K'T  in  Section  2.  Section  3 
de.scribes  the  basic  concepts  incorporated  in  PMoct. 
Section  .S  describes  the  use  of  PMoct  in  defining  and 
storing  the  policy.  In  Section  6,  an  example  of  how 
PMoct  enforces  semantic  consistency  is  presented. 
Finally,  in  Section  7.  the  benefits  of  PMoct  are  enumer¬ 
ated. 


2.  Overview  of  OCT 

In  OCT,  the  basic  data  clement  is  a  cell.  A  cell  may 
have  differen;  views:  for  example,  a  component  cell 
may  have  a  physical  view,  a  simulation  view,  a  sym- 
b<ilic  view.  etc.  Each  view  may  contain  one  or  more 


facets,  which  is  the  fundamental  unit  in  OCT  that  is 
editable  and  exists  as  a  physical  file,  while  a  cell  and  its 
views  are  directories. 

The  two  most  prevalent  facets  are  the  contents  facet 
and  the  interface  facet  The  contents  facet  holds  the 
actual  data  for  the  view  and  the  interface  facet  gives  the 
information  that  is  accessible  or  necessary  to  other 
views. 

A  facet  consists  of  a  collection  of  objects  which  are 
relmed  by  attachments  to  one  another.  This  enables  the 
formation  of  a  hierarchy  of  objects  and  a  network  of 
objects.  For  example,  a  net  object  may  have  a  number 
of  term  objects  attached  to  it.  Similarly  a  box  object 
may  be  attached  to  a  term  object  and  so  on. 

Since  OCT  docs  not  have  built  in  policies  for  the  arti¬ 
facts  used  in  electronic  design,  it  is  up  to  the  tool  devel¬ 
oper  to  give  meaning  to  the  data  stored  in  OCT  and 
hence  implement  and  enforce  (he  policy  for  a  particular 
tool.  We  have  created  PMoct  to  assist  the  user  in  speci¬ 
fying  and  maintaining  these  policies. 

3.  PMoct;  Ba.slc  Concepts 

PMoct  not  only  helps  in  maintaining  a  unified  policy 
for  a  particular  a.spect  of  the  design,  but  is  also  a  single 
tool  which  can  be  used  to  handle  the  policies  for  differ- 
cnl  design  mctliodologies  and  design  flows.  In  addition 
to  maintaining  and  creating  policies,  PMoct  has  the  fol¬ 
lowing  capabilities  that  are  not  found  in  DMoct  and 
SDL: 

•  PMoct  reduces  data  redundancy  by  allowing  a  single 
instance  of  an  object  to  be  referenced  by  any  number 
of  other  objects.  This  makes  it  unnecessary  to  find 
all  the  occurrences  of  an  object  when  maintaining 
the  library. 

•  PMoct  has  loop  constructs  to  enable  creation  of  mul¬ 
tiple  structures  of  the  same  type. 

•  PMoct  is  capable  of  getting  values  of  objects  from 
the  user.  It  has  constructs  to  specify  default  and  user 
overrideable  values  in  tire  template.. 

•  PMoct  has  a  mechanism  to  specify  sets  of  allowable 
values  for  attributes. 
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4.  PMoct:  The  Template 

The  template  Is  an  OCT  cell  having  a  name  corre¬ 
sponding  to  the  design  artifact  that  it  specifies.  An 
example  of  the  PART  Template  (cell)  is  shown  in  Fig- 
lue  3.  It  has  two  views;  the  template  viev;  that  contains 
a  contents  facet  with  the  specification  of  the  policy  and 
the  domains  view  which  contains  multiple  facets  each 
of  which  contains  a  set  of  allowable  values  for  a  partic¬ 
ular  OCT  property.  For  example  the  PARTTYPE 
shown  in  Figure  2  is  a  property  from  the  SIERA  policy 
and  may  only  take  one  of  the  following  values:  DIGI¬ 
TAL.  ANALOG.  RESISTOR.  CAPACITOR  and  CON¬ 
NECTOR.  These  are  specified  in  the  template  by 
Including  a  “PARTTYPE”  facet  under  the  domains 
view  and  putting  all  the  valid  part  types  in  that  facet. 


5.  Creating  the  Policy  Using  PMoct 

As  described  in  Section  3,  the  policy  is  defined  as  a 
contents  facet  under  the  template  view  as  shown  in  Fig¬ 
ure  4.  The  template  cell  may  be  created  manually  by 
the  user  using  tools  like  attache  or  by  running  PMoct 
on  a  text  script  written  by  the  user  in  TPL  (Template 
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Figure  5.  TOL  for  the  PART  Template 


Description  Language).  PMoct  takes  the  TDL  descrip¬ 
tion  as  shown  in  Figure  5  and  creates  the  template  cell. 
Once  the  template  cell  is  created,  PMoct  may  then  be 
used  to  create  SMVs  adhering  to  the  policy  defined  in 
the  template  contents  facet. 

The  template  contains  three  kinds  of  objects:  OCT 
objects,  command  objects  and  sequence  objects.  OCT 
objects  are  those  which  will  actu^ly  exist  in  the  final 
SMV  either  exactly  as  they  appear  in  the  template  or 
with  some  of  their  values  changed.  Command  objects 
are  used  to  specify  to  PMoct  how  the  OCT  objects  are 
to  be  processed.  The  command  objects  exist  only  in  the 
template  view  and  will  not  appear  in  the  final  SMV. 
Sequence  objects  are  required  to  maintain  an  explicit 
sequence  when  processing  the  template  because  OCT 
does  not  guarantee  any  order  for  the  retrieval  of  objects 
from  a  facet. 

All  objects  in  the  template  which  are  prefixed  by  a  “#" 
symbol  arc  command  objects.  These  are  read  and  acted 
upon  by  PMoct  as  they  are  encountered.  The  following 
subsections  give  a  brief  description  of  some  of  tlie 
commands  objects. 

When  PMoct  is  run  on  the  template,  it  processes  all  the 
objects  attached  to  the  sequence  object  with  the  value 
“I”  first  and  then  continues  in  integral  order,  that  is, 

”2”.  “.3” . The  sequence  object  “1”  must  be  specified 

even  for  a  single  object  and  the  numbering  must  be 
contiguous.  Tills  is  done  based  on  the  order  of  state¬ 
ments  in  the  TDL  descript'on  and  does  not  have  to  be 
explicitly  declared. 

5.1  Attaching  an  Object  to  Other  Objects: 
#STOR£  and  #GET 

Existing  design  management  tools  such  as  DMoct  do 
not  provide  a  mechanism  to  arbitrarily  attach  an  object 
to  more  than  one  other  object.  Attachments  are  implic¬ 
itly  hard-coded  in  DMoct.  for  example,  in  Figure  2 
every  terminal  is  attached  to  the  facet  as  well  as  to  the 
corresponding  net.  However,  this  cannet  be  specified 
explicitly  in  the  SDL  description  shown  in  Rgure  3 
from  which  tlie  SMV  of  Figure  2  was  created. 

By  contrast,  in  PMoct.  when  an  object  must  be  attached 
to  two  or  more  objects,  the  object  is  cached  by  using 
the  #STORE  command.  Then  for  every  attachment,  a 


PMoct:  A  Policy  Management  Tool  for  OCT-hased  Design  Systems  for  Multiple  IXimains 


5 


#GET  command  is  used  which  simply  gets  the  saved 
object  and  attaches  it  to  the  object  specified.  There  is 
no  restriction  on  how  many  other  objects  an  object  may 
be  attached  to. 

5.2  Controlling  Defaults  and  User  Provided 
Values:  #VAL_INVALID,  #VAL_OVERRIDE, 
#ALLOWABLE_VALUES 

All  OCT  objects  that  have  the  #VAL_1NVALID  com¬ 
mand  attached  get  their  values  horn  the  user.  For  exam¬ 
ple,  the  property  “PARTNaME”  doec  not  have  a 
default  value;  therefore,  a  #VAL_INVALID  is  attached 
to  tlie  PARTNAME  in  the  template  as  shown  in  Figure 
4.  When  PMoct  encounter  this  command  it  prompts  the 
user  for  a  value. 

If  there  is  no  #VAL_INVALID  command  attached  to 
an  object,  the  value(s)  associated  with  the  object  are 
used  as  the  default  value(s)  and  the  object  gets  created 
with  its  value(s)  being  the  same  as  the  value(s)  in  the 
template.  An  example  of  this  is  the  object  labeled 
“Prop;  Tfechnology*’  in  Figure  4  will  get  the  value 
“pebO.” 

If  a  #VAL_OVERRIDE  command  is  attached  to  an 
object  that  does  not  have  a  #VA  L_INVALID  command 
attached  to  it,  than  the  value  it  contains  is  taken  as  the 
default  and  the  user  is  prompted  to  either  accept  the 
default  value  or  enter  a  new  one. 

The  #ALLOWABLE_VALUES  command  is  used  to 
resulct  the  value  of  an  OCT  property  object  to  a 
domain  specified  in  the  domains  view  (as  described  in 
Section  4).  This  command  object  has  a  value  associated 
with  it  That  value  contains  Uie  name  of  the  facet  under 
the  domains  view  which  contains  the  set  of  allowable 
values.  When  PMoct  encounters  this  command  it  will 
present  a  list  of  “allowable  values”  that  can  be  selected 
by  the  user  to  complete  the  specification.  This  is  a  criti¬ 
cal  feature  to  ensure  consistency  across  policies. 

5.3  Creating  Multiple  Copies  of  a  Set  of 
Objects:  #REPEAT 

By  using  the  #REPEAT  command  in  PMoct  a  set  of 
objects  can  be  replicated  multiple  times.  The  set  of 
objects  to  be  replicated  is  simply  attached  to  the 
#REPEAT  command.  When  PMoct  encounters  the 


#REPEAT  command,  the  user  may  create  as  many 
copies  of  the  set  of  objects  as  required.  This  amounts  to 
a  significant  reduction  in  the  information  that  is  speci¬ 
fied  and  stored  in  the  template.  An  example,  of  using 
this  command  is  the  algorithmic  generation  of  pin 
numbers. 


6.  PMoct:  An  Example 

When  a  policy  is  defined  using  PMoct,  a  level  above 
the  SMV  is  introduced.  This  level  defined  by  the 
PMoct  template  formalizes  the  semantics  of  the  dau  in 
terms  of  the  domain.  For  example,  our  component 
library  policy  has  an  object  REF-DES-PREFIX  that 
comes  firoin  an  enumerated  set  of  values  determined  by 
IEEE  Std.  315-1975.  These  values  are  associated  with 
a  REF-DES-CLASS  object  that  is  present  in  each  com¬ 
ponent  The  values  in  REF-DES  CLASS  must  match 
the  values  used  to  determine  the  REF-DES-PREFIX. 
For  example  an  1NTEGRATED_C1RCUIT_PACK- 
AGE  is  assigned  a  "U”  as  a  prefix  and  a  CAPACITOR 
is  assigned  a  “C”.  If  the  user  does  not  use  the  same  ter¬ 
minology,  for  example,  if  IC  is  used  instead  of  the 
INTEGRATED_CIRCU1T_PACKAGE.  then  our  phys¬ 
ical  design  tools  will  not  be  able  to  find  tlie  correct  pre¬ 
fix  and  would  therefore  report  an  error.  However,  if 
PMoct  is  used  to  instantiate  a  component  SMV  in  the 
library,  the  user  will  be  prompted  to  select  the  value 
from  those  defined  for  the  REF-DES-CLASS  Domain 
View.  This  ensures  that  only  valid  REF-DES-CLASS 
values  will  be  associated  with  the  REF-DES-CLASS 
object  for  a  componenL  It  also  localizes  the  data  used 
to  determine  the  REF-DES-PREFIX  with  a  REF-DES- 
CLASS  and  new  classes  can  be  created  or  new  stan¬ 
dards  introduced  in  a  single  place.  Currently,  tools  like 
oct2rlnf  (a  translator  for  producing  Racal  Redac  Inter¬ 
mediate  Form  data  from  a  SIERA  OCT  database)  hard- 
code  this  information  in  the  program.  When  we  tried  to 
produce  a  similar  tool  for  another  design  system,  we 
had  to  duplicate  the  code  that  assigned  the  REF-DES- 
PREFIX  and  therefore  proliferated  this  information.  If 
changes  or  additions  had  to  be  made,  they  would  now 
have  to  be  carried  out  in  several  places. 

Since  PMoct  can  guarantee  that  values  used  to  create 
an  SMV  from  a  template  are  consistent  with  a  set  of 
“allowable  values"  —  these  "allowable  values”  define 
the  semantics  for  the  values  in  a  particular  domain. 


PMoct;  A  Policy  Management  Tool  for  CXJT-based  Design  Systems  for  Multiple  Domains 


6 


7.  Conclusions 

The  principal  advantages  of  storing  the  semantics  (pol-  [4] 
icy)  in  the  database  using  PMoct  tool  described  in  this 
paper  are; 

•  A  single  version  of  PMoct  can  be  used  to  manage 
data  and  design  flow  across  different  domains  of 
electronic  design  (for  example,  Integrated  circuits, 
printed  circuit  boards  and  muIUchip  modules). 

•  PMoct  makes  it  possible  to  quickly  develop  and  jgj 
integrate  new  tools  into  existing  frameworks  and 
more  importantly  to  share  tools  and  libraries  that 

exist  in  different  OCT-based  design  frameworks 
witliout  the  need  for  translators.  I  ^  j 

•  Design  instances  created  by  tools  otlier  than  PMoct 
can  be  checked  for  semantic  consistency. 

•  Translation  to  and  from  non  OCT-based  systems  can 
now  be  based  on  the  information  in  the  templates 
and  translators  can  be  specified  and  generated  auto¬ 
matically. 

•  The  policy  is  easily  modifiable  and  changes  can  be 
propagated  automatically  throughout  the  library. 

Although  PMoct  was  developed  using  OCT  for  the 
underlying  data  management  system,  the  ideas  could 
be  implemented  in  other  CAD  systems  and  with  otlier 
database  management  systems. 

Also  PMoct  would  facilitate  creating  a  CFI  (CAD 
Framework  Initiative)  compliant  interface  to  the  com¬ 
ponent  library  and  make  sharing  library  data  among 
other  CFI  compliant  CAD  systems  trivial. 
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